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Abstract 


This document specifies a particular application of the Megaco/H.248 
Protocol for control of Internet telephones and similar appliances: 
the Megaco IP Phone Media Gateway. The telephone itself is a Media 
Gateway (MG), controlled by the Megaco/H.248 Protocol, with 
application control intelligence located in the Media Gateway 
Controller (MGC). To achieve a high degree of interoperability and 
design efficiency in such end-user devices, a consistent 
architectural approach, a particular organization of Terminations and 
Packages, and a Protocol Profile are described. The approach makes 
use of existing Protocol features and user interface related 
Packages, and is thus a straight-forward application of the 
Megaco/H.248 Protocol. 


1. Introduction 


This document represents the current view from the TIA working group 
on VoIP (Voice over IP) telephone specification [1], TIA TR-41.3.4, 
with the intent of using this as part of its "whole device" 
specification as an optional method of device control. 


Industry feedback has made it clear that interoperability and 
acoustic performance of Internet telephones is key to the rapid and 
extensive commercialization of these products. To facilitate this, 
the TIA has established working group TR-41.3.4 to develop a standard 
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for VoIP telephones. The TR-41.3.4 working group has included the 

"whole device" within the scope of the standard, so a full range of 
requirements including acoustic performance, protocols, methods for 
powering and safety are provided. Where possible, the requirements 
are based on existing standards, which are included by reference. 


The TIA TR-41.3.4 working group has also recognized that its proposed 
standard must enable creative application of the equipment, encourage 
the development of new capabilities and allow for high levels of 
product customization. To achieve this, peer to peer architectures 
that are based on protocols such as H.323 or SIP and master/slave 
architectures such as Megaco/H.248 Protocol are both necessary and 
complementary. 


In support of the Megaco/H.248 Protocol development effort, the TR- 
41.3.4 working group has considered product enabling issues and 
requirements, and has developed an approach to use the Megaco/H.248 
Protocol for Internet telephone device control. This document 
represents the working group’s current view. 


This document covers the general requirements of the Megaco IP Phone 
application (section 3), architectural approach and MG organization 
(section 4), details of specific Termination types used and Packages 
supported by each (section 5), and the Megaco IP Phone Protocol 
Profile (section 6). 


2. Conventions 
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 
document, are to be interpreted as described in RFC 2119 [5]. 


3. General Requirements 


The following general requirements were identified to drive the 
Megaco IP Phone design [1]: 


1. The Megaco IP Phone must meet the basic needs of the business user 
from day one; 


2. Provide a path for rapid expansion to support sophisticated 
business telephony features; 


3. Flexibility to allow for a very wide range of telephones and 
similar devices to be defined, from very simple to very feature 


rich; 


4. Simple, minimal design; 
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5. Allow device cost to be appropriate to capabilities provided; 


6. Packages and Termination types must have characteristics that 
enable reliability; 


7. The IP Phone MG shall meet the appropriate Megaco/H.248 Protocol 
requirements as provided in the Megaco Requirements document [2] 
and be a straight-forward application of the Megaco/H.248 Protocol 
[3]. 


4. Architecture Description 


The following subsections describe the general design approach and 
organization of the Megaco IP Phone MG. 


4.1. Design Approach 


Design intent of the Megaco IP Phone is to keep it determinedly 
simple while providing required support for fully featured business 
telephones and the flexibility to allow for a very wide range of 
telephone configurations and similar appliances. 


The approach to achieve this goal is to provide a very simple and 
direct master/slave control model in which very little feature 
intelligence is required in the end device. This design intent 
matches the Megaco/H.248 Protocol approach well. 


It is important to note that additional functionality, built-in 
feature capability or system-specific optimization can easily be 
provided, at the option of the implementer, by defining additional 
Termination types, Event/Signal Packages, or providing built-in 
application capability. This document defines the minimal design 
only. 


4.2. General Structure 


As shown in Figure 1 below, the Megaco IP Phone is organized as a 
Media Gateway (MG) that consists of a User Interface Termination and 
a set of Audio Transducer Terminations. 


Several - potentially thousands - of Megaco IP Phone MGs may be 
controlled by a single Media Gateway Controller (MGC). This is 
distinguished from the organization between traditional analog or PBX 
telephones behind an IP network, where the MGC would control an MG 
which in turn controls the collection of telephone devices in 
question. In the case of a Megaco IP Phone MG, the MG directly 
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implements the media terminations like handset, handsfree and 
headset, as well as the user interface. In this case, the Megaco IP 
Phone itself is the MG. 
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Figure 1: Megaco IP Phone Termination / Package Model 
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4.3. Termination / Package Organization 


As shown in Figure 1, each Audio Transducer Termination represents an 
individually controllable audio input/output element of the telephone 
device, such as Handset, Handsfree, Headset, etc. By separating each 
audio element as a distinct Termination, more flexible applications 
can be easily implemented, such as paging, group listening, and so 
on. Since this is actually only the logical view of the device, 
represented by protocol, it is also quite possible to simplify 
representation of the device by hiding all available audio 
input/outputs behind a single Audio Transducer Termination, for 
example the Handset, and implement control of multiple real 
input/outputs locally inside the device. 


All non-audio user interface elements are associated with the User 
Interface Termination. This special Termination supports Packages to 
implement all user interaction with the telephone user interface, 
including Function Keys, Indicators, the Dialpad, etc, as appropriate 
for the specific device capabilities (within constraints given in the 
section on User Interface Termination). The User Interface 
Termination cannot be placed in any Context. This grouping of user 
interface elements behind a well-know Termination greatly simplifies 
audits to determine actual device configuration, and reduces the 
number of Terminations involved in representing user interface. 


In addition, TerminationID naming conventions are provided to 
identify specific Terminations within the Megaco IP Phone MG and 
group them into related sets. These conventions use a set of well 
known identifier names to specify the individual Terminations, for 
example the User Interface Termination ("ui"), the Handset Audio 
Transducer ("at/hs"), or the Handsfree Audio Transducer ("at/hf"). 
This specific naming is important in this application, especially for 
the Audio Transducer Terminations, since the real input/output 
elements to which they map on the physical device have very different 
functional significance to the end-user, yet they may be represented 
in the protocol using exactly the same sets of Packages. Naming 
conventions allow the controlling MGC to distinguish this end-user 
meaning without specific advance knowledge of physical device 
configuration and without the requirement to provide different 
Packages for each audio input/output type. 


Using these same TerminationID naming conventions in combination with 
wildcards, the MGC application can target commands to groups of 
related Terminations, for example the collection of all Audio 
Transducer Terminations ("at/*"). This is especially useful during 
the discover phase, for example to efficiently Audit all available 
Audio Transducer Terminations, and to efficiently send commands to a 
set of related Terminations in a single command, for example to 
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simultaneously Subtract all Audio Transducer Terminations from a 
particular Context. Further information on TerminationID naming 
conventions and their use can be found under the sections on Control 
Interaction and Capability Discovery (next two subsections) and under 
Termination Types. 


4.4. Control Interaction 


To provide control of audio paths, Audio Transducer Terminations are 
manipulated using Contexts in the normal way, by sending Add, Move, 
Subtract and Modify commands addressed to the specific Terminations 
being manipulated. For example creating a Context (Context A) 
containing an RTP Termination (Tr) and a Handset Audio Transducer 
Termination (Tal) creates a voice connection to/from the handset. 
Moving a Handsfree Audio Transducer Termination (Ta2) into the 
Context, and removing the Handset, sets up a handsfree conversation. 
This situation is shown in Figure 1. See the section on Audio 
Transducer Termination Types for further details on specific Package 
support requirements. 


User input elements, such as Keypad or Function Keys, generate Events 
through Notify commands sent from the User Interface Termination of 
the Megaco IP Phone MG to the controlling MGC for handling. These 
Events are according to the specific set of Packages supported by the 
User Interface Termination of the device. See the section on User 
Interface Termination Type for further details on specific Package 
support requirements. 


User output elements such as the Text Display or Indicators are 
controlled by Signals sent by the MGC, addressed to the User 
Interface Termination of the Megaco IP Phone MG, generally as part of 
a Modify command, using syntax defined in the corresponding Packages. 
Since the User Interface Termination cannot be part of any context, 
Add, Move and Subtract commands sent to it are not valid. See the 
section on User Interface Termination Type for further details on 
specific Package support requirements. 


Some elements, for example Softkeys, have both user input and output 
aspects, so both react to Signals and generate Events as above. 


The TerminationID naming conventions may be used to target commands 
to specific Terminations by well known name, for example to Add the 
Handsfree Audio Transducer Termination ("at/hf") to a Context. The 
naming conventions in combination with wildcards may be used to 
efficiently send commands to groups of related Terminations, for 
example to simultaneously Subtract all Audio Transducer Terminations 
("at/*") from a particular Context. 
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4.5. Capability Discovery 


At startup or service change, the Megaco IP Phone MG identifies 
itself to its controlling MGC as being a Megaco IP Phone class of 
device by use of the IPPhone Protocol Profile. This is the first and 
most important stage of capability discovery, and implicitly provides 
a great deal of the necessary information in a single step. 
Thereafter, the MGC can make a large number of assumptions regarding 
organization and behavior of the MG. See the section on IPPhone 
Protocol Profile for further details of ServiceChange operation. 


Device capabilities, including the list of all Terminations and 
supported Packages for each, are queried through the AuditValue 
command. Wildcarded AuditValue commands targeted at the whole MG 
(i.e., addressed to ContextID=Null, TerminationID=ALL) return the 
list of all Terminations, including the User Interface Termination 
and all supported Audio Transducer Terminations. Since the returned 
TerminationIDs use well known identifier names, the MGC can derive 
the specific audio input/output elements available on the physical 
device, and their intended purpose. Further AuditValues commands on 
individual named Terminations provide further details of each, for 
example for the MGC to query user interface support Packages 
available on the User Interface Termination ("ui"). TerminationID 
naming conventions in combination with wildcards can be used with 
AuditValues commands to query specific Package support for the 
collection of all Audio Transducer Terminations ("at/*"). 


Since the structure of the Megaco IP Phone MG is well known in 
advance, by virtue of the IPPhone Protocol Profile, audits can be 
efficiently directed at discovering only what additional information 
is required by the MGC. Thus the MGC is able to efficiently and 
unambiguously discover both the specific user interface capabilities 
and the supported audio input/outputs of the Megaco IP Phone MG, 
without specific advance knowledge of physical device configuration. 
It is not necessary for the MGC to attempt to infer function from 
supported Packages within a random collection of Terminations, anda 
great deal of behavior common to all Megaco IP Phone MGs can simply 
be assumed. This pre-determined organization and behavior therefore 
greatly reduces design complexity of both MG and MGC, and greatly 
improves interoperability. 


5. Termination Types 
The Termination types defined for use in the Megaco IP Phone MG are: 


* User Interface (implements user interface); 
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* Audio Transducer (implements audio input/output to the user, and 
potentially appears as several individual Terminations 
corresponding to individual audio input/outputs on the physical 
device); 


* RTP (transport of audio streams over IP). 
These Termination types represent minimal capabilities to support 
fully featured business telephones. Additional Termination types can 


be defined to extend these capabilities. 


The following subsections describe requirements and constraints on 
each type in further detail. 


5.1. User Interface Termination Type 


The User Interface Termination represents the Megaco IP Phone MG user 
interface elements. Megaco IP Phone MGs MUST support exactly one 
User Interface Termination. 


TerminationID of the User Interface Termination MUST be "ui", used 
for both command addressing and command response return. ABNF text 
encoding for this MUST be as described in Megaco/H.248 Protocol 
Appendix B.1 [3]. 


Note: If ASN.1 binary encoding is used (OPTIONAL in this 
specification), TerminationID for the User Interface Termination MUST 
be encoded as described in Megaco/H.248 Protocol Appendix A.1 [3], 
with alphabetic characters of the identifier given above mapping to 
the equivalent octet string in the ASN.1 encoding. 


The User Interface Termination cannot be part of any context, hence 
Add, Move and Subtract commands are invalid for this Termination. 


The User Interface Termination MAY support the following Packages, 


defined in Megaco/H.248 Protocol H.248 Annex G: "User Interface 
Elements and Actions Packages" [4]. 
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| Package | Name | Support in User Interface | 
| | | Termination | 
| Text Display | dis | OPTIONAL | 
| Keypad | kp | OPTIONAL | 
| Function Key | kf | OPTIONAL | 
| Indicator | ind | OPTIONAL | 
Softkey | ks OPTIONAL | 
| Ancillary Input anci OPTIONAL 
| | | 


Additional Packages not listed above MAY also be provided where these 
are defined to extend to additional user interface elements. 


Note: The reasoning to make all Packages optional in the User 
Interface Termination is to allow maximum flexibility to create a 
very broad range of Internet telephones and similar devices. For 
example, anything from a simple hotel lobby phone (handset and 
hookswitch only), to conferencing units (handsfree unit and one or 
two buttons) to fully featured business telephones (display, rich set 
of keys and indicators, both handset and handsfree, etc) could be 
designed. 


5.2. Audio Transducer Termination Types 


The Audio Transducer Terminations are used to control audio 
input/output to/from the end user of the device. Megaco IP Phone MGs 
MUST support at least one Audio Transducer Termination, which MAY be 
chosen from the following well known types (with identifier name): 


* Handset ("hs") -- input/output, 
* Handsfree ("hf") -- input/output, 
* Headset ("ht") -- input/output, 
* Microphone ("mi") -- input only, 

* Speaker ("sp") -- output only. 


TerminationIDs of the Audio Transducer Terminations MUST be of the 
form "at/<name>", where <name> is the 2 character identifier listed 
above, used for both command addressing and command response return. 
If more than one Audio Transducer Termination of a particular type is 
implemented, the TerminationIDs of each MUST be of the form 
"at/<name>/<num>", where <num> is a 2 digit index number in 


hexadecimal format beginning at 01. Examples of valid TerminationIDs 
include: "at/hs" (handset), "at/mi/02" (microphone 2), "at/*" (all 
audio input/outputs). ABNF text encoding for this MUST be as 


described in Megaco/H.248 Protocol Appendix B.1 [3]. 
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Note: If ASN.1 binary encoding is used (OPTIONAL in this 
specification), TerminationIDs and wildcards MUST be encoded as 
described in Megaco/H.248 Protocol Appendix A.1 [3], with alphabetic 
characters of the identifiers given above mapping to octet sub- 
strings in the ASN.1 encoding and the ’/’ character not used. 


Additional Audio Transducer Termination types MAY also be defined by 
the implementer, however well know identifier names for these are 
outside the scope of this specification. 


All Audio Transducer type Terminations MUST support the following 
Packages, defined in Megaco/H.248 Protocol Annex E [3]. 


| Package | Name | Support in Audio Transducer | 
| | Terminations 

| Basic DTMF Generator| dg | REQUIRED | 

| Call Progress Tones | cg | REQUIRED | 

| Generator | | | 

| | | | 


Additional Packages not listed above MAY also be provided where 
applicable to audio input/output functions. 


5.3. RTP Termination Type 


Megaco IP Phone MGs MUST support at least one RTP Termination in 
order to support audio streams to/from the device, as defined in 
Megaco/H.248 Protocol Annex E.12 [3]. 


No special TerminationID naming convention is defined for RTP 
Terminations as part of this specification. 


6.  IPPhone Protocol Profile 


The following subsections provide details of the IPPhone Protocol 
Profile, used between Megaco IP Phone MGs and their controlling MGCs. 
This includes implicit application-level agreements between the 
Megaco IP Phone MG and its controlling MGC on organization and 
behavior of the MG, types of Terminations used and the specific 
minimum Package support for each, and specific minimum selections on 
the transport and encoding methods used. 


Use of a this Profile greatly simplifies assumptions necessary by the 
MGC regarding MG organization, thereby reducing complexity and cost 
of both MG and MGC, and improves interoperability for the specific 
Megaco IP Phone application. Since the Profile is specific to the 
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Megaco IP Phone MG, no other applications of Megaco/H.248 Protocol 
are affected. 


It is important to note that the IPPhone Profile specifies minimum 
functionality only, for interoperability purposes. Additional 
Termination types, Package support, transport or encoding methods, or 
other capabilities MAY be added at the discretion of the implementer 
within the general structure described. 


6.1. Profile Descriptor and Usage 


Profile name: "IPPhone" 
Version: 1 


The Megaco/H.248 Protocol [3] describes startup and service change 
procedures in detail, including use of Profiles. 


In brief, the above Profile name and version are supplied by the 
Megaco IP Phone MG on startup or at service change, in the 
ServiceChangeDescriptor parameter of the ServiceChange command, 
issued to the controlling MGC as part of the registration procedure. 
In response, the MGC may 1) accept control by acknowledging the 
Service Change, 2) pass control to a different MGC by replying with a 
new MGC to try, or 3) refuse control entirely by rejecting the 
Service Change. If MGC control is refused, the Megaco IP Phone MG 
may attempt registration with other MGCs in its list of MGCs to try. 


Once a controlling MGC accepts the IPPhone Profile, both it and the 
Megaco IP Phone MG become bound by the Profile rules and constraints 
described in subsequent subsections as well as Megaco IP Phone 
Termination/Package organization and behavior rules described in 
previous sections of this document. Thereafter, any protocol use 
outside these rules is considered an error. 


6.2 Termination Organization and Package Support 
Termination organization, required Termination types, and the 


specific Packages supported by each MUST be as described in sections 
4 - 5 of this document. 


Note that additional Termination types and Package support MAY also 
be provided within the general structure described. 


6.3. Transport 
Megaco IP Phone MGs MUST support Application Layer Framing (ALF) over 


UDP transport, as specified in the Megaco/H.248 Protocol Appendix D.1 
[3]. 
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6. 


8. 


Note that this does not imply that the Megaco IP Phone MG cannot 
support other transport methods as well. TCP transport is OPTIONAL, 
but if used MUST conform to Megaco/H.248 Protocol Appendix D.2 [3]. 


Message Encoding 


Megaco IP Phone MGs MUST support ABNF text encoding of the protocol, 
as specified in the Megaco/H.248 Protocol Appendix B [3]. 


Note that this does not imply that the Megaco IP Phone MG cannot 
support ASN.1 binary encoding as well. ASN.1 binary encoding is 
OPTIONAL, but if used MUST conform to Megaco/H.248 Protocol Appendix 
A [3]. 


Security Considerations 


The Megaco IP Phone Media Gateway Application Profile adds no new 
security issues beyond those endemic to all applications of 
Megaco/H.248 Protocol [3]. 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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